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(54) Signalling of bouquet information in a digital transmission system 



(57) A method of transmission of digital information 
in a digital communication network, the network com- 
prising at least one transport stream carrying one or 
more bouquet related tables such as BAT tables 53, 54 
containing information regarding the services provided 
in a commercial bouquet and characterised In transmit- 
ting at least one table 51 comprising a list of bouquet 
identity values of some or all ot the bouquet association 
tables together with an Indication of the or each trans- 



port stream carrying that table or tables. In a particularly 
preferred embodiment, the table 51 containing a list of 
bouquet identity values may correspond to the Network 
Information Table of a network. 

The present invention also extends to the identifi- 
cation of any fixed RID. TID tables that may only be dis- 
tinguished by their TID extension values. 

The present invention is particularly applicable to 
digital television systems conforming to the MPEG-2 
and DVB proposed standards. 
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Description 

[0001] The present invention relates to a method and apparatus tor use in a digital transmission system, in particular 

a digital television system. 

s [0002] Existing digital television systems transmit data in the form of discrete transport stream packets or transport 
packets, each packet being of a predetermined length and containing a header and a payload. The MPEG-2 standard 
is the currently favoured standard in this domain and sets out a predetermined format for such packets. 
[0003] The packet header comprises genera! descriptive data regarding the packet, whilst the payload comprises 
the data to be processed at the receiver. The packet header includes at least a packet ID or PID identifying the packet. 

10 The payload of the packet may contain audio, video or other data such as conditbnal access system data or, in par- 
ticular, application data used by the decoder to set up interactive or other applications. Data within a PID packet may 
further be divided into a number of tables or sections, identified by a table ID or TID value and, in a yet further precision, 
a TID extension value. 

[0004] Data in a conventional transport stream is organised as follows. At the highest level, a programme access 
IS table or PAT table lists the PID values of one or more programme map tables or PMT tables, each PMT table being 
associated with a sen/ice within the transport stream. The PMT table in turn refers to the PID values of the packets 
containing the audio data, video data, application data etc. for that service. As will be understood, whilst a set of sen^ices 
may be considered as corresponding loosely to a television channel, the concept of a service is slightly different, since 
a digital channel may contain multiple audio and/or visual data streams, only application data etc. 
20 [0005] Conventionally, the MPEG-2 standard fixes the PID value of the PAT program access table at 0x00 to enable 
any MPEG conforming system to immediately access program data. Other than for this table, and for the conditional 
access or CAT table, the MPEG-2 standard does not generally define fixed packet ID or table ID values, leaving this 
as a choice to the implementor of the system. 

[0006] In this regard, the work done by other groups, notably the Digital Video Broadcasting or DVB group, compte- 
rs ments and elaborates on the MPEG standard. Although not a standardisation body per se, DVB has been active in 
defining a number of proposed standards relating to digital broadcasting, these standards subsequently being adopted 
by organisations such as the European Telecommunications Standards Institute or ETSI. 

[0007] The ETSI standard ETS 300 468 defines characteristics of a number of additional data tables having fixed 
PID and TID values. These tables include a Network Information Table or NIT, a Service Description Table or SDT and 

30 a Bouquet Association Table or BAT. For further information, the reader Is referred to this published document as well 
as the associated technical reports ETR 162 and ETR 211 , all of which are freely available from the ETSI offices. 
[0008] The following discussion will focus on the Bouquet Association Table or BAT This table, at present optional, 
seems likely to play an increasingly important role in future implementations of broadcast digital television systems. 
[0009] Typically, one commercial operator is responsible for the content of a plurality of service channels, these 

35 channels being grouped together as a bouquet of services. The BAT table is used to provide Information regarding the 
bouquet of services and has a fixed PID, TID value of 0x001 1 , 0x44. In addition to a list of the services associated with 
this bouquet, it may also include other information relating to the bouquet, such as subscription details etc. 
[0010] A network manager, such as a cable host or satellite sen/ice provider, is responsible for the conveyance or 
transmission of a plurality of transport streams. At present, operator bouquets are rigidly separated between transport 

40 streams, each transport stream carrying only services relating to one bouquet offering. In such circumstances, a trans- 
port stream nornnally only contains a single BAT table which may be easily located and downloaded by a decoder. 
[0011] However, the evolution of the market and the increasing syndication of services or channels in a number of 
bouquets means that this structure is breaking down. As such, it is likely that a bouquet in the future may comprise 
services spread over a number of different transport streams. Locating BAT table information in such systems will 

45 become increasingly Important. 

[001 2] According to a first aspect of the present Invention there is provided a method of transmission of digital infor- 
mation in a digital communication network, the network comprising at least one packet transport stream carrying one 
or more tables containing information relating to a commercial bouquet and characterised in transmitting at least one . 
other table comprising a list of bouquet identity values associated with information identifying at least one transport 

so stream so as to enable identification of some or all of the bouquet related tables with the corresponding transport 
stream or streams. 

[001 3] In particular, the bouquet related table may correspond to a bouquet association table, containing information 
regarding the services present in a commercial bouquet. Whilst the present invention is particularly applicable in relation 
to bouquet association tables carrying service informatran associated with a commercial bouquet, it may also be applied 
ss to other tables containing bouquet information, for example application descriptor tables carrying information regarding 
interactive applications associated with a bouquet offering. 

[0014] The provision of a table providing an overview of the bouquet association tables in the network and their 
location within a transport stream enables a receiving device to quickly and effectively identify and filter out a required 
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bouquet association table. This could otherwise prove difficult in the case where a plurality of bouquet association 
tables are-transmitted in a single transport stream since the tables normally all have identical PID, TID values and may 
only be identified by a TID extension value, which value may not be known to a decoder. 

[0015] A number of implementations are jaossible. In one embodiment, a generalised table comprising a list of bou- 
quet identity values associated with a plurality of the transport streams in the network is provided, this generalised 
table being transmitted in each of the corresponding transport streams in the network. 

[0016] In one embodiment, the generalised table may correspond to a network information table or NIT used to 
convey information regarding all the transport streams in a network. Such a table may include other information such 
as the tuning frequency of the transport stream etc. 

[001 7] The advantage of using a NIT type table to carry the bouquet table data is that the NIT table is accessible via 
all transport streams in a network. Accordingly, a decoder may download the table at any time and when tuned to any 
transport stream or service. In particular, since the NIT table is usually downloaded at start up (to enable a decoder to 
have access to channel frequencies etc.) the decoder may also take in bouquet table information at that time. 
[0018] As will be understood, whilst it is usually advantageous to use a network type table covering all transport 
streams in the network, partial tables covering a selected group of transport streams within a network may also be 
envisaged. This will be discussed in further detail below. 

[0019] In addition to transmission of a generalised table regarding bouquet association table data relating to the 
network carrying the table, one embodiment may also provide for the transmission in a network transport stream of a 
generalised table comprising a list of all bouquet ids associated with some or all transport streams of another network. 
[0020] Whilst the use of a generalised table to convey bouquet identity values for all transport streams is particularly 
convenient, this is not the only possibility and, in other circumstances, other embodiments may be preferable. In par- 
ticular, in a network comprising a large number of transport streams, these transport streams may be organised in 
groups, information and services being shared only between the transport streams in each group. 
[0021] In such circumstances, there may be no need to provide a complete universal table covering all BATs in all 
transport streams in the network and a solution based on use of a partial table covering only transport streams within 
a group and broadcast on all transport streams within that group may be used. 

[0022] Altematively, sufficient information may be provided by transmission within each transport stream of one or 
more transport stream specific tables. Accordingly, according to one embodiment, a transport stream specific table is 
transmitted in a transport stream, this table comprising a list of bouquet identity values associated with that particular 
transport stream. 

[0023] Unlike the generalised table, where a list of transport stream id values and bouquet table id values are pro- 
vided, the link between a bouquet id and a transport stream is simply provided by the fact that a bouquet id Is carried 
in a table specific to a given transport stream. 

[0024] Preferably, the transport stream specific table corresponds to a service description table, used to convey 
information regarding the services carried in that transport stream. In a particularly preferable embodiment, the bouquet 
identity values are further associated with each of the services listed in the service description table. 
[0025] In addition to transmitting a table regarding the bouquet ids associated with the transport stream used to 
convey that table, the method may also comprise transmitting in one transport stream a table comprising a list of 
bouquet identity values associated with another transport stream, for example, in the same network, or even in another. 
[0026] The present invention is particularly applicable to a method of transmission in which all bouquet association 
tables are identified with a predetermined packet id and table id value. For example, in a DVB conforming system, all 
bouquet association tables are identified by the PID, TID values 0x0011 , 0x4A. 

[0027] In such an embodiment, each bouquet association table may be identified by a table id extension value, this 
value corresponding to the bouquet identity value. For example, in a DVB conforming system the table id extension 
value of a BAT table is Identical to the bouquet id assigned to an operator by the European Broadcasting Union. 
[0028] The above description of the present invention has concentrated on a method of transmission of digital infor- 
mation. 

[0029] Viewed from another aspect, the present invention comprises a method of processing digital information re- 
ceived via a digital communication network characterised in downloading from a transport stream at least one table 
comprising a list of bouquet identity values associated with the or each bouquet association table, the bouquet identity 
value or values being identified with the corresponding transport stream or transport streams conveying the bouquet 
association table, and using this information to download one or more bouquet association tables conveyed in one or 
more transport streams! 

[0030] Preferred embodiments of such a method may concentrate on the downloading of information as described 
in relation to the various transmission embodiments, e.g. using generalised network tables, transport stream specific 
tables etc. 

[0031] The present invention has been described above in relation to accessing tables containing bouquet related 
information. It may however be extended to other sorts of tables having fixed packet identity and table identity values 
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to the following figures, in which: 

Figure 1 shows the overall architecture of a digital TV system according to this embodiment; 

Figure 2 shows the architecture of the conditional access system of Figure 1 ; 

Figure 3 shows the structure of transport packet and table data within a broadcast transport stream; 

Figure 4 shows the structure of a Bouquet Association Table carried within the broadcast transport stream of Figure 

3; 

Figure 5 shows the structure of a Network Information Table carried within the broadcast transport sUeam of Figure 

3; and 
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; transmits compressed digital signals to a transmitter 6 of the broadcast centre via iinKage 

a wide variety of forms including telecom links. ,«^arri«i a satellite transponder 9, where they 
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of a dish owned or rented by the end user. The signals received by receiver 11 are transmitted to an integrated receiver/ 
decoder 1 2 owned or rented by the end user and connected to the end user's television set 1 3. The receiver/decoder 
12 decodes the compressed MPEG-2 signal into a television signal for the television set 13. 

[0043] A conditional access system 20 is connected to the multiplexer 4 and the receiver/decoder 1 2. and Is located 
5 partly in the broadcast centre and partly in the decoder. It enables the end user to access digital television broadcasts 
from one or more broadcast suppliers. A smartcard. capable of decrypting messages relating to commercial offers 
(that is, one or several television programmes sold by the broadcast supplier), can be inserted into the receiver/decoder 
12. Using the decoder 12 and smartcard. the end user may purchase events in either a subscription mode or a pay- 
per-view mode. 

10 [0044] An interactive system 1 7, also connected to the multiplexer 4 and the receiver/decoder 12 and again located 
partly In the broadcast centre and partly in the decoder, may be provided to enable the end user to interact with various 
applications via a modemmed back channel 16.* 



75 



35 



Conditional Access System 



[0045] With reference to Figure 2, in overview the conditional access system 20 includes a Subscriber Authorization 
System (SAS) 21. The SAS 21 is connected to one or more Subscriber Management Systems (SMS) 22. one SMS 
for each broadcast supplier, by a respective TCP-IP linkage 23 (although other types of linkage could alternatively be 
used). Alternatively, one SMS could be shared between two broadcast suppliers, or one supplier could use two SMSs, 
20 and so on. 

[0046] First encrypting units in the form of ciphering units 24 utilising "mother" smartcards 25 are connected to the 
SAS by linkage 26. Second encrypting units again in the form of ciphering units 27 utilising mother smartcards 28 are 
connected to the multiplexer 4 by linkage 29. The receiver/decoder 12 receives a "daughter" smartcard 30. It is con- 
nected directly to the SAS 21 by Communications Sen/ers 31 via the modemmed back channel 16. The SAS sends, 

25 amongst other things, subscription rights to the daughter smartcard on request. 

[0047] The smartcards contain the secrets of one or more commercial operators. The "mother" smartcard encrypts 
different kinds of messages and the "daughter" smartcards decrypt the messages, if they have the rights to do so. 
[0048] The first and second ciphering units 24 and 27 comprise a rack, an electronic VME card with software stored 
on an EEPROM. up to 20 electronic cards and one smartcard 25 and 28 respectively, for each electronic card, one 

30 card 28 for enciypting the ECMs and one card 25 for encrypting the EMMs. 

[0049] The operation of the conditional access system 20 of the digital television system will now be described in 
more detail with reference to the various components of the television system 2 and the conditional access system 20. 



Multiplexer and Scrambler 



[0050] With reference to Figures 1 and 2, in the broadcast centre, the digital audio or video signal is first compressed 
(or bit rate reduced), using the MPEG-2 compressor 3. This compressed signal is then transmitted to the multiplexer 
and scrambler 4 via the linkage 5 in order to be multiplexed with other data, such as other compressed data. 
[0051] The scrambler generates a control word used in the scrambling process and included in the MPEG-2 stream 
40 in the multiplexer. The control word is generated internally and enables the end user's integrated receiver/decoder 12 
to descramble the programme. 

[0052] Access criteria, indicating how the programme is commercialised, are also added to the MPEG-2 stream. The 
programme may be commercialised In either one of a number of "subscription" modes and/or one of a number of "Pay 
Per View" (PPV) modes or events. In the subscription mode, the end user subscribes to one or more commercial offers, 
45 or "bouquets", thus getting the rights to watch every channel inside those bouquets. In the preferred embodiment, up 
to 960 commercial otters may be selected from a bouquet of channels. 

[0053] In the Pay Per View mode, the end user is provided with the capability to purchase events as he wishes. This 
can be achieved by either pre-booking the event in advance ("pre-book mode"), or by purchasing the event as soon 
as it is broadcast ("impulse mode"). In the preferred embodiment, all users are subscribers, whether or not they watch 
50 in subscription or PPV mode, but of course PPV viewers need not necessarily be subscribers. 

Entitlement Control Messages 

[0054] Both the control word and the access criteria are used to build an Entitlement Control Message (ECM). This 
55 is a message sent in relation with a scrambled program; the message contains a control word (which allows for the 
descrambling of the program) and the access criteria of the broadcast program. The access criteria and control word 
are transmitted to the second encrypting unit 27 via the linkage 29. In this unit, an ECM is generated, encrypted and 
transmitted on to the multiplexer and scrambler 4. During a broadcast transmission, the control word typically changes 
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every tew seconds, and so ECMs are also periodically transmitted to enable the changing control word to be descram- 
bled. For redundancy purposes, each ECM typically includes two control words; the present control word and the next 

control word. ^ * » 

[0055] Each service broadcast by a broadcast supplier in a data stream comprises a number of distinct components, 
for example a television programme includes a video component, an audio component, a sub-title component and so 
on Each of these components of a sen/ice is individually scrambled and encrypted for subsequent broadcast to the 
transponder 9. In respect of each scrambled component of the service, a separate ECM is required. Alternatively, a 
single ECM may be required for all of the scrambled components of a service. Multiple ECMs are also generated in 
the case where multiple conditional access systems control access to the same transmitted program. 

Programme Transmission 

[0056] The multiplexer 4 receives electrical signals comprising encrypted EMMs from the SAS 21 , encrypted ECMs 
-from the second encrypting unit 27 and compressed programmes from the compressor 3. The multiplexer 4 scrambles 
the programmes and sends the scrambled programmes, the encrypted EMMs and the encrypted ECMs to a transmitter 
6 of the broadcast centre via the linkage 7. The transmitter 6 transmits electromagnetic signals towards the satellite 
transponder 9 via uplink 8. 

Programme Reception 

[0057] The satellite transponder 9 receives and processes the electromagnetic signals transmitted by the transmitter 
6 and transmits the signals on to the earth receiver 11 . conventionally in the form of a dish owned or rented by the end 
user via downlink 10. The signals received by receiver 11 are transmitted to the integrated receiver/decoder 1 2 owned 
or rented by the end user and connected to the end user's television set 13. The receiver/decoder 12 demultiplexes 
the signals to obtain scrambled programmes with encrypted EMMs and encrypted ECMs. 

[0058] If the programme is not scrambled, that is, no ECM has been transmitted with the MPEG-2 stream, the re- 
ceiver/decoder 12 decompresses the data and transforms the signal into a video signal for transmission to television 
set 13 

[0059] If the programme is scrambled, the receiver/decoder 1 2 extracts the corresponding ECM from the MPEG-2 
stream and passes the ECM to the "daughter" smartcard 30 of the end user. This slots into a housing in the receiver/ 
decoder 1 2 The daughter smartcard 30 controls whether the end user has the right to decrypt the ECM and to access 
the programme If not, a negative status is passed to the receiver/decoder 12 to indicate that the programme cannot 
be descrambled If the end user does have the rights, the ECM is decrypted and the control word extracted. The 
decoder 12 can then descramble the programme using this control word. The MPEG-2 stream is decompressed and 
translated into a video signal for onward transmission to television set 1 3. 

Entitlement Management Messages (EMMs) 

[0060] The EMM is a message dedicated to an individual end user (subscriber), or a group of end users. Each group 
may contain a given number of end users. This organisation as a group aims at optimising the bandwidth; that is, 
access to one group can permit the reaching of a great number of end users. 

[0061] Various specific types of EMM can be used. Individual EMMs are dedicated to individual subscribers, and are 
typically used in the provision of Pay Per View services; these contain the group identifier and the position of the 

subscriber in that group, ^ 
[0062] Group subscription EMMs are dedicated to groups of. say, 256 individual users, and are typically used in the 
administration of some subscription services. This EMM has a group identifier and a subscribers' group bitmap. 
[0063] Audience EMMs are dedicated to entire audiences, and might for example be used by a particular operator 
to provide certain free services. An "audience" is the totality of subscribers having smartcards which bear the same 
conditional access system identifier (CA ID). Finally, a "unique" EMM is addressed to the unique identifier of the smart- 
card. 

Subscriber Management System (SMS) 

[0064] A Subscriber Management System (SMS) 22 includes a database 32 which manages, amongst others, all of 
the end user files, commercial offers, subscriptions. PPV details, and data regarding end user consumption and au- 
thorization. The SMS may be physically remote from the SAS. 

[0065] Each SMS 22 transmits messages to the SAS 21 via respective linkage 23 which imply modifications to or 
creations of Entitlement Management Messages (EMMs) to be transmitted to end users. 
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[0066] The SMS 22 also transmits messages to the SAS 21 which imply no modifications or creations of EMMs but 

imply only a change in an end user's state (relating to the authorization granted to the end user when ordering products 
or to the amount that the end user will be charged). 

[0067] The SAS 21 sends messages (typically requesting information such as call-back information or billing infor- 
5 mation) to the SMS 22. so that it will be apparent that communication between the two is two-way. 

Subscriber Authorization System (SAS) 

[0068] The messages generated by the SMS 22 are passed via linkage 23 to the Subscriber Authorization System 
10 (SAS) 21 , which in turn generates messages acknowledging receipt of the messages generiated by the SMS 21 and 

passes ihese acknowledgements to the SMS 22. 

[0069] In overview the SAS comprises a Subscription Chain area to give rights for subscription mode and to renew 
the rights automatically each month, a Pay Per View Chain area to give rights for PPV events, and an EMM Injector 
for passing EMMs created by the Subscription and PPV chain areas to the multiplexer and scrambler 4, and hence to 

IS feed the MPEG stream with EMMs. If other rights are to be granted, such as Pay Per File (PPF) rights in the case of 
downloading computer software to a user's Personal Computer, other similar areas are also provided. 
[0070] One tunction of the SAS 21 is to manage the access rights to television programmes, available as commercial 
offers in subscription mode or sold as PPV events according to different modes of commercialisation (pre-book mode, 
impulse mode). The SAS 21 , according to those rights and to information received from the SMS 22, generates EMMs 

20 for the subscriber. 

[0071] The EMMs are passed to the Ciphering Unit (CU) 24 for ciphering with respect to the management and ex- 
ploitation keys. The CU completes the signature on the EMM and passes the EMM back to a Message Generator (MG) 
in the SAS 21 , where a header is added. The EMMs are passed to a Message Emitter (ME) as complete EMMs. The 
Message Generator determines the broadcast start and stop time and the rate of emission of the EMMs, and passes . 
25 these as appropriate directions along with the EMMs to the Message Emitter. The MG only generates a given EMM 
once; it is the ME which performs cyclic transmission of the EMMs. 

[0072] On generation of an EMM, the MG assigns a unique identifier to the EMM. When the MG passes the EMM 
to the ME, it also passes the EMM ID. This enables identification of a particular EMM at both the MG and the ME. 
[0073] In systems such as simulcrypt which are adapted to handle multiple conditional access systems e.g. associ- 
30 ated with multiple operators, EMM streams associated with each conditional access system are generated separately 
and multiplexed together by the multiplexer 4 prior to transmission. 

[0074] There will now be described the format and organisation of packet and table data within a given transport 
stream. 

35 Format of Transport Packets and Private Section Data 

[0075] As is known, MPEG transport packets are of a fixed length of 188 bytes including a header. In a standard 
packet, the three bytes of the header following the synchronisation data comprise: 



TABLE I 



Transport error indicator 


.1 bit 


Pay load unit indicator 


1 bit 


Transport priority 


1 bit 


PID 


1 3 bits 


Transport scrambling control 


2 bits 


Adaptation field control 


2 bits 


Continuity counter 


4 bits 



50 [0076] The characteristics of these fields are largely determined by the MPEG standard. 

[0077] The above describes the format of the header of a transport packet In conformity with the MPEG-2 standard, 
information contained with a packet payioad is subject to a further level of structure according to the type of data being 
transported. In the case of audio, visual, teletext, subtitle or other such rapidly evolving and synchronised data, the 
information is assembled In the form of what is known as a packetlsed elementary stream or PES. This data stream, 

55 which is formed by assembling the payloads of the transmitted packets, itself comprises a sequence of packets, each 
packet comprising a packet header and payioad. Unlike the transmitted packets in the transport stream, the length of 
PES packets is variable. 

[0078] In the case of some other types of data, such as application data or ECM and EMM data, a different format 
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from PES packeting is proscribed. In particular, data contained in the transport packet payload is divided into a series 
of sections or tables, the table or section header including a table ID or TID identifying the table in question. A table 
may also be identified by a further parameter, namely a table ID extension value. Depending on the size of the data, 
a table may be contained entirely within a packet payload or may be extended in a series of sections over a number 
of transport packets. In the MPEG-2 context, the term "table" or "section" is often used to refer to a single isolated table 
of data. The term "section" may also refer to one of a plurality of tables with the same TID value. 
[0079] The actual TID or TID extension values used to refer to infomnation carried in private tables or sections are 
not fixed by the MPEG-2 standard and may be defined at the discretion ot the operator of a service or bouquet of 
services. 

[0080] As with transport packet data and PES packet data, the data structure or syntax of a table or section is nev- 
ertheless additionally defined by the MPEG-2 standard. Two possible syntax forms for private table or section data are 

proposed; a long form or a short form. 

[0081] In both the short and long form, the header of a private table includes at least the data comprising: 



TABLE II 


Table id 


8 bits 


Section syntax indicator 


1 bit 


Private indicator/reserved 


1 bit 


ISO reserved 


2 bits 


Section length 


12 bits 



[0082] The private indicator and private section lengths are comprised of data not fixed by the MPEG-2 standard 
and which may be used by the system operator for his own purposes. For further information regarding table syntax, 
the reader is referred to the MPEG-2 standard. 

Oroanisation of Data Tables within the Transport Stream 

[0083] As shown in Figure 3, the broadcast data transport stream contains a number of packets of standard format, 
including a programme association table 40 ("PAT"), the PID in the header of the packet being fixed by the MPEG-2 
standard at a value of 0x00. The programme access table 40 provides the entry point for access to programme data 
and contains a table referring to the PID values of the programme map tables ("PMT") 41 , 42 associated with a given 
service within the stream. A service is uniquely defined by a triplet of the values original network id, transport stream 
id and service id. 

[0084] Each programme map table 41 , 42 contains in turn a reference to the PID values of the packet streams of 
the audio tables 43 and video tables 44 associated with a transmission. As shown, the programme map table 42 also 
contains references to the PID values of other packets 45, 46 containing additional data relating to the transmission 
in question, in particular, ECM data generated by a number o1 conditional access systems and associated with the 
transmission in question as well as application data. 

[0085] In addition to the programme access table PAT 40, the MPEG transport stream further comprises a conditional 
access table 47 ("CAT"), the PID value of which is fixed at 0x01 . The CAT table 47 refers to the PID values of MPEG 
packets 48, 49, 50 conveying EMM data associated with one or more conditional access systems. As with the PMT 
packets, the PID values o1 the EMM packets referred to in the CAT table 47 are not fixed and may be determined at 
the choice of the system operator. 

[0086] Outside of the PAT table value and the CAT table value referred to above, the MPEG-2 standard specifies 
very few fixed PID values. Whilst the MPEG-2 standard foresees the use of other tables. In particular a Network Infor- 
mation Table (NIT), the standard does not dictate the PID value of this or other tables, but merely indicates that they 
can be addressed via the PAT table, in the same manner as the PMT tables associated with the services in a given 
transport stream as described above. 

[0087] As discussed in the introduction, the work done by the Digital Video Broadcasting or DVB group to some 
extent complements the MPEG-2 set of standards. In particular, the January 1997 version of the DVB proposed Eu- 
ropean Telecommunication Standard 300 468 sets out the characteristics of a number of other tables and defines their 
PID and TID values. 

[0088] The tables defined therein include, inter, alia, a Network Information Table (NIT) shown at 51 in Figure 3. a 
Service Description Table (SDT) shown at 52 and a Bouquet Association Table (BAT) shown at 53, 54. Other tables 
are also defined In this standard, but will not be discussed hereafter for the sake of brevity. 

[0089] The NIT table, which will be described in lurther detail below, contains Information regarding each and all of 
the transport streams carried by a network operator, such as the particular tuning frequency associated with a transport 
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stream etc. This table Is obligatory in DVB compatible systems and is typically created by the network manager re- 
sponsible for relaying the various transport streams, for example, a satellite or cable network manager 
[0090] The NIT table may also include information regarding the services in each transport stream also supplied to 
the network manager by each sen/ice provider. The NIT table is universal and is included in all transport streams within 
5 that network. As indicated in Figure 3 and as with all MPEG type tables, the NIT table may be in practice divided into 
a number of sections. 

[0091] In the DVB standard ETS 300 468. the RID and Tl D values of the NIT table network have been fixed at 0x001 0 
and 0x40, respectively, overcoming the need to locate the table via the PAT table. The values 0x0010, 0x40 are asso- 
ciated with the NIT table for the host network, that is. the network tor which the transport stream containing the NIT 
10 table forms a part. It is also foreseen that NIT tables regarding another network may also be carried in the transport 
stream and such tables are assigned the RID, TID values 0x0010 and 0x41, respectively. 

[0092] An SDT table within a transport stream is also obligatory in DVB compatible systems. The SDT table contains 
the unique name of each service, given by the triplet of original network id, transport stream id and sen/ice id values, 
together other parameters regarding each service such as the status of a sen/ice (running, not running etc.), timing 

IS information etc. As before, the table may be divided into a number of sections. 

[0093] The SDT table is assigned the respective fixed RID, TID values 0x0011 , 0x42 by the DVB standard. As with 
the NIT table, it is also foreseen that a given transport stream may also carry an SDT table regarding information in 
other transport streams. In such a case, the SDT table is assigned the PID, TID values OxOOn , 0x46. 
[0094] The DVB standard also defines the characteristics of a Bouquet Association Table or BAT. used to group 

20 together information regarding the services associated with a service bouquet proposed by a commercial operator. In 
a given transport stream, a BAT table provides information regarding a bouquet having access to services within that 
stream. As with the SDT and NIT tables, the BAT table may be divided between a number of sections. 
[0095] The structure of BAT table as defined by ETS 300 468 is shown in Figure 4. The BAT table contains, inter 
alia, information regarding the bouquet id. a unique value assigned by the European Broadcasting Union to a bouquet 

2S provider. Current holders of bouquet id values are listed in the DVB technical report ETR 162. 

[0096] The BAT also contains in the descriptor part of the table information regarding each of the services offered 
by that bouquet as identified by their unique triplet value described above and associated with the corresponding 
transport stream. The BAT table may equally be used to carry commercial data, such as subscription details for a given 
bouquet. As will be described below, the increasing complexity of bouquet offerings in relation to services broadcast 

30 over a number of transport streams means that the use of a BAT table will become increasingly important to provide 
a complete overview of services within a bouquet. 

[0097] In particular, applications run on a decoder such as an electronic program guide or the like, may use the 
information contained within the BAT table in their operation, for example, to display program or service information 
for these services contained within the bouquet or bouquets to which the decoder has access or even to other bouquets. 
35 In such a context, it is essential that a decoder be able to distinguish between BAT tables associated with a number 
of different operators. 

[0098] In a vertical market, such as exists today, all sen/ices within a transport stream are associated with a single 
bouquet offering and are described by a single BAT table within that transport stream. An operator proposing an alter- 
native bouquet of services uses a separate transport channel to carry his services. In such an environment, each 
40 transport channel is associated with a unique bouquet offering and conveys a unique BAT information table. 

[0099] In certain cases, a service or program may be syndicated to and form part of the bouquet of multiple operators. 
The news channel CNN typically forms part of the bouquet offered by a number of operators, for example. With the 
segregation between transport stream and bouquet described above, the sen^ice must be recopied into each of the 
transport streams in question. 

45 [0100] With changing market conditions, it is increasingly probable that this sort of organisation of bouquet sen/ices 
and transport channels will not be maintained. A service broadcast in one transport stream may then be associated 
with a number of bouquets. Correspondingly, a given bouquet may comprise a number of sen/ices spread over a 
plurality of transport streams. 

[0101] In this sort of environment, the situation may arise where multiple BAT tables are carried in a single transport 
so stream, as represented by the BAT tables 53, 54 shown in Figure 3. These BAT tables may represent a bouquet 
conveying services in that transport stream or even in another transport stream. 

[0102] Such tables have identical PID, TID values 0x0011, 0x44 and may only be distinguished using a series of 
unique TID extension values. In practice, these PID extension values are identical to the bouquet id values assigned 
by an international organisation, such as the European Broadcasting Union. In order to enable a decoder to correctly 
55 access a given BAT table amongst the multiple tables included in the transport stream, the TID extension, or bouquet 
id value must therefore be communicated to the decoder 

[0103] The following example of the invention will be discussed in relation to identification of BAT tables within a 
transport stream. However, the same principle may be applied to other tables containing bouquet related information. 
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such as a table listing interactive applications otfered in a bouquet or. indeed, any fixed PID and TID value table that 
can only be identified by a generally unknown TID extension value. 

[0104] In one embodiment of the invention, this information may be conveniently located in a NIT table. Referring to 
Figure 5. the structure of an exemplary NIT table according to the DVB standard is shown. As will be seen, in addition 
to the part of the table concerning the network itsell. the number of sections making up the table etc.. the table further 
includes a second loop of information regarding the characteristics of each of the transport streams carried in the 
network, indicated by: 



trans port_streamJoopJength 

for (i=0;i<N;i++){ 

transport_streamJd 
originaLnetworkJd 
reserved Juture.use 
transport_descriptors_length 

lor (j=0;i<N;j++){ 
descriptorO 



} 



12 bits 



16 bits 
16 bits 
4 bits 
12 bits 



[01 05] Within the descriptor ( ) part associated with each transport stream identified in the NIT table, it would therefore 
30 be convenient to include a description of each of the BAT tables carried within that stream, as follows: 



35 



40 



45 



so 



55 



descriptor_tag 
descriptorjength 
for (i=0;i<n;i-H-) { 
bouquetjd 



8 bits 



8 bits 



16 bits 



[01 06] As mentioned above, once created, the NIT table for a network is included in all transport streams carried by 
that network. In view of the other information contained within the NIT table (transport stream frequency etc.). this table 
is usually immediately downloaded by a decoder as part of the start-up operations of a decoder, so as to enable the 
decoder to tune to the correct transport stream frequencies etc. 

[0107] Introduction ol a descriptor section identifiable by a descriptor tag and providing information concerning the 
BAT table extension values for each BAT table within a transport stream thus enables a decoder to assimilate and 
store this information during this initial start-up period. Thereafter, applications running within the decoder and requiring 
access to information contained in one or more BAT tables will possess the TID extension and transport stream id data 
necessary to select and download a given BAT table within a given transport stream. 

[01 08] Whilst the placement of this information within an NIT table provides a particularly convenient way to enable 
a decoder to access BAT data for all transport streams in a single operation, other realisations are possible. For ex- 
ample, in an alternative embodiment, a section identifying the bouquet id values of the BAT table or tables within a 
given transport stream may be included within the SDT table associated with that transport stream. 
[0109] As described above. SDT tables idenfified by PID. TID values 0x0011 . 0x42 are normally used to carry infor- 
mation regarding each of the sen/ices carried in the transport stream containing that table. As will be appreciated, it 
would be relatively straightfonward to introduce in this table a descriptor section containing a list of bouquet ids asso- 
ciated with the BAT tables carried in the particular transport stream containing that SDT table. 
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[0110] Referring to Figure 6, the structure of a standard SDT table is shown. In this embodiment, the bouquet id 
values are linked to a transport stream by the fact that each SDT table is specific to a given transport stream 
[0111] In point of tact, a further level of identification may be carried out by assoceting the bouquet id values with 
each of the services listed in the SDT as defined in the second indented loop of the table. It may be the case, for 
example, that certain services with a transport stream belong to different bouquet operators. Identification of service 
information with bouquet information enables any decoder downloading the SDT table to identify and handle the sen^- 
ices accordingly. 

[0112] In particular, the information may be used to identify and select tables other than a BAT table, such as an 
application description table relating to interactive applications carried by the various sen/ices. 
[Oil 3] In comparison with the NIT based realisation described above, this embodiment suffers from the disadvantage 
that It is not possible to obtain information regarding the BAT tables across all transport streams in a single operation. 
However, as mentioned above, SDT tables assigned the PID, TID values 0x0011 , 0x46 and regarding sen/ices in other 
transport streams may also be conveyed by a transport stream. These tables may also be modified to include infor- 
mation regarding the BAT tables in these corresponding other transport streams so as to enable a decoder to download 
BAT table information regarding some or all of the other transport streams handled by the networtc. 
[0114] In certain cases, for example, where transport streams within a network are not all inter-related but are divided 
into a series of sub-groups, this embodiment may be in practice just as convenient as the use of a universal network 
table. 

[0115] Other embodiments are equally possible, for example, by creating a dedicated table containing bouquet id 
and transport stream data and identified by a unique PID, TID value pair, to be later defined. This dedicated table may 
be either generalised and inserted across all transport streams within a network, as with a NIT table, or specific to each 
transport stream, as with an SDT table. In addition or as an alternative to the assignment of fixed PID, TID values, 
such a table may also be located or accessible via a reference in another table within the transport stream. 
[0116] The bouquet id and transport stream data may also be incorporated within other tables contained within a 
transport stream, not yet defined and which may be again generalised across the network or specific to a transport 
stream. For example, the f^PEG group is presently considering the introduction of another pre-determined and fixed 
value table, the Transport Stream Description Table, used primarily to carry information regarding the physical char- 
acteristics of a transport stream, and which may be modified to include such information. 

[0117] Whilst the above description has concentrated upon the implementation of such a system within the digital 
satellite TV domain, it will be understood that the invention is equally applicable to digital communication networks in 
general, such as digital terrestrial television networks, cable networks, combination broadcasting/cable systems etc. 



Claims 

1. A method of transmission of digital information in a digital communication network, the network comprising at least 
one packet transport stream carrying one or more tables containing information relating to a commercial bouquet 
and characterised in transmitting at least one other table comprising a list of bouquet identity values associated 
with information identifying at least one transport stream so as to enable identification of some or all of the bouquet 
related tables with the corresponding transport stream or streams. 

2. A method as claimed in claim 1 , in which a bouquet related table corresponds to a bouquet association table 
containing informations regarding the services present in a commercial bouquet. 

3. A method as claimed in claim 1 or 2, in which a generalised table comprising a list of bouquet identity values 
associated with a plurality of the transport streams in the network is provided, this generalised table being trans- 
mitted in each of the corresponding transport streams In the network. 

4. A method as claimed in claim 3. in which the generalised table corresponds to a network information table used 
to convey information regarding all the transport streams in the network. 

5. A method as claimed in any preceding claim, in which a transport stream is provided comprising a generalised 
table comprising a list of bouquet identity values associated with some or ail of the transport streams of another 
network. 

6. A method as claimed in claim 1 or 2, in which a transport stream specific table is transmitted in a transport stream, 
this table comprising a list of bouquet identity values associated with that particular transport stream. 
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7. A method as claimed in claim 6. in which the transport stream specific table corresponds to a service description 
table, used to convey information regarding the sen/ices carried in that transport stream. 

8. A method as claimed in claim 7. in which the bouquet identity values are further associated with each of the sen/ices 
listed in the sen/ice descriptor table. 

9. A method as claimed in any of claims 6 to 8. further comprising transmitting in one transport stream a table com- 
prising a list of bouquet identity values associated with another transport stream. 

10. A method as claimed in any preceding claim, in which alt bouquet association tables in a network are identified 
with a predetermined packet id and table id value. 

11. A method as claimed in claim 10, in which a bouquet association table is identified by a table id extension value, 
this value corresponding to the bouquet identity value. 

12. A method as claimed in any preceding claim as applied to transmission of a digital television system. 

13. A method of processing digital information received via a digital communication network characterised in down- 
' loading from a transport stream at least one table comprising a list ot bouquet identity values associated with the 

or each bouquet association table, the bouquet identity value or values being identified with the corresponding 
transport stream or transport streams conveying the bouquet association table, and using this information to down- 
load one or more bouquet association tables conveyed in one or more transport streams. 

1 4. A method as claimed in claim 1 3, comprising downloading a generalised table comprising a list of bouquet identity 
values associated with a plurality of transport streams in the network. 

15. A method as claimed in claim 1 3. comprising downloading a transport stream specific table, this table comprising 
a list of bouquet identity values associated with one particular transport stream. 

1 6. A method as claimed in any of claims 1 3 to 1 5 as applied to reception of digital television signal. 

17. A digital television signal comprising at least one transport stream carrying one or more bouquet association tables 
containing information regarding the services provided in a commercial bouquet and characterised in that the 
digital television signal includes at least one table comprising a list of the bouquet identity values of some or all of 
bouquet association tables together with an indication of the or each transport stream carrying that table. 

1 8 A method of transmission of digital information in a digital communication network, the network comprising at least 
' one packet transport stream carrying one or more designated tables identified with a fixed packet identity value 
and a fixed table identity value and having a variable table extension or similar value and characterised in trans- 
mitting at least one other table comprising a list ot table extension values of the designated table or tables asso- 
ciated with information identifying at least one transport stream carrying the designated table or tables. 

1 9. A method as claimed in claim 1 8 in which a generalised table comprising a list of table extension values associated 
" with a plurality of the transport streams in the network is provided, this generalised table being transmitted in each 

of the corresponding transport streams in the network. 

20. A method as claimed in claim 18. in which a transport stream specific table is transmitted in a transport stream, 
this table comprising a list of table extension values of the designated table or tables assoceted with that particular 
transport stream. 
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